Part of #6884.

This will make it possible to create invite-QR codes for broadcast channels, and make them symmetrically end-to-end encrypted.

I posted the benchmark results at #6884 (comment)

Overview of the protocol when both sides have multi-device

The technical design

The QR codes / invite links and the network protocol build on the securejoin protocol in order to secure broadcast channels against MitM attacks, to securely exchange key material, and to add a member to the broadcast channel.

The mentioned securejoin protocol has 4 steps of exchanging messages. Rather than using the same protocol for broadcast channels, I will implement an improved protocol consisting of only 2 steps, described below. I will call it Securejoin v2.

The securejoin v2 protocol has these advantages over the old protocol:

• Less complexity (the protocol is now completely stateless on both sides except for creating the chats, and no 'shortcut' if Bob already knows Alice's key)
• Faster (fewer messages need to be exchanged)
• Slightly smaller QR codes (no need for a separate INVITE token)
• No unencrypted messages at all

If Securejoin v2 turns out to work nicely for broadcast channels, we can also use them for group and 1:1 invites, and remove the code for securejoin v1.

The QR code / invite link scheme

I will call the channel owner's device "Alice" and the device of the user who scans / clicks on the invite link "Bob".

Alice creates an invite link like this; QR codes contain the same text.

https://i.delta.chat/#FINGERPRINT&a=ADDR&b=BROADCAST_NAME&x=BROADCAST_ID&s=AUTH

where:

• FINGERPRINT is the OpenPGP fingerprint of the channel owner, which will allow the Bob to verify that the messages come from the correct sender, and that there is no MitM attack.
• ADDR is Alice's address, which will Bob to contact Alice.
• BROADCAST_NAME is the user-visible name of the broadcast channel, so that the user can be asked "Do you want to subscribe to BROADCAST_NAME"? after scanning the QR code / clicking the link.
• BROADCAST_ID is an internal ID, used in the database to correctly distinguish channels.
• AUTH is a secret token, used for two purposes:
  1. It allows Bob to send a symmetrically encrypted message to Alice, even though he doesn't have her public key yet.
  2. It allows Alice to verify that Bob actually scanned a QR code that allows him to join a channel.

The network protocol for joining a channel - Securejoin v2

In summary, Bob sends a message that is encrypted symmetrically with the AUTH token. Alice answers by adding Bob to the broadcast channel, and sending the broadcast channel's shared secret to Bob.

This is adapted from https://securejoin.readthedocs.io/en/latest/new.html:

1. a) Alice generates an invite code for this broadcast channel.

   b) The AUTH token is generated specifically for this broadcast channel; Alice remembers in the tokens SQL table that this AUTH token belongs to this broadcast channel.

2. a) Bob (the user) scans the QR code or clicks on the link. Bob saves Alice's fingerprint into the database and creates the broadcast channel chat; only messages signed with this fingerprint will be allowed in the broadcast channel.

   b) Bob sends a message with the header Secure-Join: vb-request-with-auth to Alice. (vb-request-with-auth follows the scheme of the securejoin v1 messages).

   In the encrypted part, this message contains Bob's own fingerprint Bob_FP in the header Secure-Join-Fingerprint.

   This message additionally contains all the information Delta Chat adds in every message: Bob's public key (so that Alice can send private messages to Bob), as well as Bob's display name and avatar (so that Alice can see who joined her channel; note that Delta Chat makes it easy to create an anonymous profile where the name and avatar are not identifying).

3. Alice decrypts Bob's vb-request-with-auth message using the AUTH token from step 1

   a) and verifies that Bob’s Autocrypt key matches Bob_FP and that the transferred AUTH matches the one from step 1.

   b) If any verification fails, the protocol terminates.

4. a) Alice adds Bob to the broadcast channel in her database,

   b) and sends a message with the header Secure-Join: vb-member-added to Bob.

   This message contains the broadcast channel's shared secret in the header Chat-Broadcast-Secret.

   This message is asymmetrically encrypted with Bob's public key; alternatively, it could be encrypted with the AUTH token, or with both the public key and the AUTH token.

5. Bob saves the shared secret into his database and is now able to decrypt messages that are sent into the channel.

If this network protocol works nicely in practice, we can start using it also for normal contact/group invites.

The symmetric encryption

Symmetric encryption uses a shared secret. Currently, we use AES128 for encryption everywhere in Delta Chat, so, this is what I'm using for broadcast channels (though it wouldn't be hard to switch to AES256).

• The AUTH token used to encrypt vb-request-with-auth has 144 bits of entropy (see fn create_id in the code). If and when we switch to AES256, we can just generate larger AUTH tokens.
• The secret shared between all members of a broadcast channel has 258 bits of entropy (see fn create_broadcast_shared_secret in the code).

Since the shared secrets have more entropy than the AES session keys, it's not necessary to have a hard-to-compute string2key algorithm, so, I'm using the string2key algorithm salted. This is fast enough that Delta Chat can just try out all known shared secrets. ¹ In order to prevent DOS attacks, Delta Chat will not attempt to decrypt with a string2key algorithm other than salted ².